Octane and service providers have somewhat delicate relationship. You have to consider a lot of nuances when creating a provider that should work with Octane. One careless resolution of a singleton during the boot process can cause strange behaviors, if the state is not handled correctly.

Currently, for most of the first-party packages, application state is managed in an Octane compatible way. Also, if you are writing an application or a package yourself, there are sufficient mechanisms to run it safely on Octane.

However, problems start to arise when you use third-party packages which might not be Octane friendly. That can cause bugs so critical that you might even consider ditching Octane altogether (speaking from personal experience). Right now, to make sure that the third-party packages work safely with Octane, you have to check every service provider of every package (even the ones that you are not using directly). Inspecting the third-party codebase, you should check for the singletons which are resolved during the boot process and add them to the octane.flush config. This will get the instances deleted after each request/operation. It must also be mentioned that you will also need to do that for every update, because any update may introduce new “unsafe” singleton resolutions. This means that you can not reliably use most of the community packages with Octane, limiting you from enjoying the Laravel Ecosystem fully.

With this PR, I am proposing to add the ability for Laravel Octane to register (and boot) specific service providers on each request/operation, rather than during the boot process. The list of the specific providers can be managed through configuration. With this approach, all singleton associated issues become easily manageable as it allows developers to simply use third-party packages in an Octane safe way. If Octane is considered as a future default runtime for Laravel (we think so) based applications, more and more packages will become Octane friendly and if that’s the case, developers can always manage to revert back to the traditional booting process through configuration.

To sum up, as a result of merging this PR, Laravel Octane will become safer to use in combination with any third party package, which in turn will encourage the community to more actively adopt Octane, without second thoughts about the problems it may cause.

This solution comes in two parts, second part is a minor refactor of the framework, please refer to the PR in laravel/framework.

If I am missing something, please fill free to share your thoughts. Any insights are highly appreciated.